Web-based electronically signed documents

ABSTRACT

Techniques for electronic signature process management are described. Some embodiments provide an electronic signature service (“ESS”) configured to manage electronic signature processes represented by way of templates. In some embodiments, the ESS transmits a URL or other identifier of a template that specifies required electronic signature data, such as a singer name and/or signature. Then, the ESS dynamically prepares a form based on a received request for the identified template. Next, the ESS receives the electronic signature data by causing the form to be presented by a Web browser or other client. In some embodiments, the ESS and associated client systems perform these techniques without use of a Portable Document Format processing module.

PRIORITY CLAIM

This application is a continuation of application Ser. No. 13/158,937filed on Jun. 13, 2011 and claims the benefit of U.S. ProvisionalApplication Ser. No. 61/354,155 filed on Jun. 11, 2010, the contents ofwhich are incorporated by reference.

FIELD OF THE INVENTION

The present disclosure relates to methods and systems for electronicsignatures and, more particularly, to methods and systems for managingWeb-based electronic signature processes.

BACKGROUND OF THE INVENTION

In one approach to managing an electronic signature process, a documentis emailed or otherwise transferred to a user (a “signer”) who engagesin a signature process with respect to the document. Upon receipt, thesigner signs the document, after which data from the signed document istransferred to a server or other location for storage.

The above-described approach suffers from a number of drawbacks. First,common implementations of this approach typically require specializedsoftware, such as Portable Document Format (“PDF”) processing software.Moreover, the PDF processing software often needs to be speciallyconfigured to facilitate the signature process. Second, PDF and itsrelated processing software may suffer from security vulnerabilitiesthat can be exploited by malicious parties for various purposes, therebyrendering the signature process unreliable. Third, such an approachtypically statically defines the document for signature such that thedocument cannot easily be modified in light of newly receivedinformation, particularly when the document has been previously sent tothe signer.

SUMMARY OF THE INVENTION

In one embodiment, a method in an electronic signature service forfacilitating electronic signatures includes, without use of a PDFprocessing module, transmitting a URL or other identifier thatidentifies a template that specifies required electronic signature data;receiving a request based on the transmitted URL; in response to thereceived request, preparing a form based on the template; presenting theform within a Web browser; and receiving the required electronicsignature data.

In other embodiments, systems and computer-readable media forfacilitating electronic signatures by an electronic signature serviceare provided.

In further embodiments, client side methods, systems, andcomputer-readable media for interacting with an electronic signatureservice are provided.

BRIEF DESCRIPTION OF THE DRAWINGS

Preferred and alternative examples of the present invention aredescribed in detail below with reference to the following drawings:

FIG. 1 illustrates an exemplary block diagram of an embodiment of anelectronic signature service in accordance with the present invention;

FIG. 2 is an exemplary flow diagram of an electronic signature serviceprocess performed by an embodiment of the present invention;

FIG. 3 is an exemplary flow diagram of an electronic signature clientprocess performed by an embodiment of the present invention;

FIGS. 4A-4N are user interface screens and controls provided by anexemplary embodiment of the present invention; and

FIG. 5 is a block diagram of a computing system for practicing exemplaryembodiments.

DETAILED DESCRIPTION

Embodiments described herein provide enhanced computer- andnetwork-based methods and systems for obtaining and managing electronicsignatures and, more particularly, for creating, managing, and utilizinga dynamic Web-based electronic signature process. Example embodimentsprovide an electronic signature service (“ESS”) configured to facilitatecreation of a template that specifies required electronic signaturedata. In one embodiment, the electronic signature service is furtherconfigured to provide an identifier of the template, such as a uniformresource locator (“URL”), a uniform resource identifier (“URI”), anetwork file identifier or path, or the like. This identifier can beprovided to a signer in various ways, such as by being placed on a Webpage for access by a Web browser operated by the signer. When the ESSlater receives a request based on the provided identifier, the ESSdynamically prepares a form based on the template. This form istransmitted to the signer, who in turn uses it to provide the requiredelectronic signature data to the ESS. The ESS stores the providedelectronic signature data for use by other components or parties.

FIG. 1 illustrates an exemplary block diagram of an example embodimentof an ESS in accordance with the present invention. In particular, FIG.1 illustrates an ESS 100 that includes logic 102, a templates datarepository 104 and a signature data repository 106.

A template creator user 110 uses a client device 120 (e.g., a personalcomputer, a laptop computer, a smart phone) to create a template. Thecreated template specifies, indicates, or identifies required electronicsignature data, such as a signer name, a signature, a date, and thelike. Template creation in one example embodiment is described furtherwith reference to FIGS. 4A-4N, below. The created template is stored bythe ESS 100 in the templates data repository 104.

In the illustrated example, the ESS 100 provides a uniform resourcelocator (“URL”) to a Web server 130. The Web server 130 hosts Web pagesand/or code modules (e.g., server and/or client side code, servlets,plug-ins, scripts) that facilitate transactions that require electronicsignatures. For example, the Web server 130 may host a human resourcesWeb site that facilitates requests for or related to personal time off,vacation time, sick leave, retirement account contributions, and otherpersonnel matters. In other embodiments, the Web server 130 may host anonline shopping facility, an online banking service, a governmentservice, or the like.

A signer user 111 uses a client device 121 (e.g., a personal computer, alaptop computer, a smart phone) to perform a transaction facilitated bythe Web server 130. For example, the signer user 111 may use the clientdevice 121 to submit a request for personal time off to the Web server130. In response, the Web server transmits the URL that identifies thetemplate to the client device 121. The transmitted URL may be embeddedin a Web page as a link or other element (e.g., button).

The client device 121 then transmits a request based on the received URLto the ESS 100. In one embodiment, the request is transmitted via HTTP,HTTPS, or some other protocol specified by the URL. The transmittedrequest may include all or some of the URL (e.g., the hierarchicalportion of the URL including a host name and path name) as well as dataobtained by the client device 121 and/or the Web server 130. For examplethe client device 121 may initially present a form to gather or obtaindata from the signer 111, such as a name, address, employeeidentification number, or other information. This obtained data may beincorporated or included as part of the transmitted request. In oneembodiment, the obtained data is appended onto the URL (or portionthereof) as a query string (e.g., as in an HTTP GET request) or othertype of parameters (e.g., embedded in the request as HTTP POST data).

In response to the request received from the client device 121, the ESS100 dynamically prepares a form based on the request and/or the templateidentified by the request. The form may include or otherwise becustomized based on additional data appended to the URL or otherwisetransmitted along with the received request as discussed above. Forexample, if the signer's name and address were appended to the URL, thenthe form may be customized to include this information, thereby savingthe signer 111 the steps of having to re-enter this information duringthe signature process. The prepared form may be, include, or specifyuser interface controls that are configured to obtain the requiredsignature data from the signer 111. The prepared form is transmitted tothe client device 121, where it is presented to the signer 111, such aswithin the context of a Web browser or other client application. Thesigner 111 then provides the required signature data via the preparedform to the ESS 100.

The ESS 100 then stores the received required signature data in thesignature data repository 106. The required signature data is then madeavailable for access by other components or users. For example thetemplate creator 110 or some other administrative user (e.g., a humanresources administrator) can access the required signature data toverify that the signer 111 has provided the required electronicsignature.

In at least some embodiments, the techniques described herein do notrequire the use of a Portable Document Format (“PDF”) processing module(e.g., viewer, reader, editor) by any of the elements involved in asignature process. In the example of FIG. 1, neither the client devices120-121 nor the ESS 100 have or utilize a PDF module to perform any ofthe described acts or functions. In particular, the client device 121,in obtaining the required signature data does not use a PDF module(e.g., to present and/or fill out a form). Instead, the client device121 receives and renders the form only via well-known Web standards,such as HTTP, HTML, and the like. By not relying on the PDF format orrelated processing modules, the described approaches can advantageouslybe deployed in environments where PDF processing modules may not beavailable or configured to facilitate form-filling operations or thelike, including feature phone or smart phone settings where PDF supportmay be minimal or entirely lacking

Also, the techniques described herein can be employed to overcome oravoid problems related to “stale” or inconsistent forms. In priorapproaches, forms may become stale or inconsistent with one another orassociated templates because form documents may have long lifetimes thatare independent of their associated signature processes and/ortemplates. For example a form document (e.g., represented as a PDF file)may be transmitted via an email and stored for a period of time (e.g., aweek or longer) before the signer signs the form. In the meantime,however, the signature process associated with the form document mayhave changed (e.g., to require additional information), resulting in aninconsistency between the originally transmitted form and the modifiedsignature process.

Such problems with “stale” or inconsistent forms are avoided when usingthe presently described approach. In particular, because the ESS 100uses a “late binding” approach that dynamically generates a form inresponse to a received request, modifications to the associated formtemplate can be reflected in the generated form, even when the formtemplate is modified after the URL is initially transmitted. In oneembodiment, after transmitting the URL that identifies a template, thetemplate may be modified, such as to include additional requiredelectronic signature data. Then, in response to a received request, theESS 100 prepares the form to include controls for receiving theadditional required electronic signature data. Thus, even though thetemplate was modified after transmission of the URL, the modifiedaspects of the template were still reflected in the prepared formtransmitted to the client.

FIG. 2 is an exemplary flow diagram of an electronic signature serviceprocess performed by an embodiment of the present invention. Inparticular, FIG. 2 illustrates a process that may be implemented by, forexample, one or more elements of the ESS 100, such as the logic 102,described with reference to FIG. 1. The process provides a dynamicallygenerated form based on a received request that identifies a formtemplate that specifies required electronic signature data.

The process begins at block 202, where it transmits a URL thatidentifies a template that specifies required electronic signature data.Typically, the transmitted URL is then embedded in a Web page or otherdocument (e.g., email) that can be accessed on a client device forpurposes of performing a transaction that requires an electronicsignature.

At block 204, the process receives a request based on the transmittedURL. The received request may include one or more arguments or otherdata along with at least a portion of the transmitted URL. For example,a script or other code executing on a client device may have obtainedinformation about a signer user, and included that information asarguments in the request, such as represented by a URL query string ofone or more key value pairs.

At block 206, the process prepares a form based on the template and thereceived request. Preparing the form may include dynamically generatinga form based on the template, where the form is populated to includearguments or other data that are part of the request received at block204. The form may be represented, for example, as markup code (e.g.,HTML code) and/or instructions (e.g., JavaScript instructions).

At block 208, the process presents the form. Presenting the form mayinclude transmitting the form to a client device that is executing a Webbrowser. In other embodiments, other types of client applications may beutilized, such as a mobile application (e.g., an “app”) executing on asmart phone. The Web browser then renders the transmitted form andreceives the required signature data as user inputs to the form.

At block 210, the process receives the required electronic signaturedata. For example, the process may receive the required electronicsignature data from a Web browser that is executing on a client deviceand that has rendered the form transmitted as described with respect toblock 208. The Web browser may transmit the form data to the process inresponse to a user selection, such as selection of a “submit” button orother control. The received required electronic signature data may bestored or in some cases transmitted to one or more recipients specifiedby the template or another mechanism.

The process may perform other operations in addition to or instead ofthose described above. For example, in one embodiment, the process doesnot utilize, directly or indirectly, a PDF processing module during anyof its operations. As another example, in some embodiments, the processmay enforce usage restrictions specified by templates. For example, ausage restriction may specify a maximum number of times or frequencythat a template can be used for electronic signature purposes. If themaximum number is exceeded, the process may refuse to prepare andtransmit a form.

FIG. 3 is an exemplary flow diagram of an electronic signature clientprocess performed by an embodiment of the present invention. Inparticular, FIG. 3 illustrates a process that may be implemented by orwithin a Web browser or other code module executing on the client device121 described with respect to FIG. 1. The process interacts with anelectronic signature service process (e.g., FIG. 2) in order toimplement an electronic signature process.

The process begins at block 302, where it receives a URL that identifiesa template managed or stored by an electronic signature service. Thetemplate specifies electronic signature data that is required torepresent a complete electronic signature. In other embodiments, othermechanisms for identifying the template may be used, such as networkfile system file or resource identifiers.

At block 304, the process transmits a request based on the received URL.In some embodiments, the request is dynamically generated by the processbased on the received URL and includes at least a portion of thereceived URL as well as other data or arguments. For example, therequest may be generated by a script executing on a Web browser that hascollected data values from a user. In generating the request, the scriptmay incorporate the collected data values into the request, such as byappending them to the URL as a query string comprising one or more keyvalue pairs. The request may be transmitted to the electronic signatureservice (e.g., using the HTTP protocol) in order to obtain a form forcollecting required electronic signature data.

At block 306, the process receives a form prepared based on thetemplate. As discussed above, the electronic signature service preparesa form based on the transmitted request. The prepared form is thentransmitted from the electronic signature service to the illustratedprocess.

At block 308, the process collects required electronic signature data bypresenting the received form. For example if the form is represented asHTML, the process may render the form in a Web browser or similarrendering component. Alternatively, the form may be represented as acode module (e.g., an applet or script). In such a case, the processpresents the received form by executing or interpreting the code module.A user of the process can then use the presented form to input therequired electronic signature data.

At block 310, the process transmits the collected electronic signaturedata to the electronic signature service. As discussed above, theelectronic signature service then stores the electronic signature datafor use or access by other users or system components.

WEB POWERFORMS EMBODIMENT

The following describes an exemplary embodiment referred to herein asthe “Service,” and based on Web POWERFORMS service offered by DocuSign,Inc. The Service facilitates the creation of an online-signing process,seamlessly integrated into a Web portal, intranet, email, document orother technology using only, in an embodiment, user interface tools. Noprogramming is required to create this integrated experience.

The Service provides a user the ability to click a URL link, be placedin a form collecting their name and email address, and then beimmediately placed in a Web user interface to complete a documentsigning. The Service further includes the ability for the technology todynamically add the appropriate recipient information, place these datain the document to be signed, and present a customized, integrateddocument signing.

When the user clicks the URL link, a “virtual sender” initiates sendingof a pre-described document. This allows the on-demand creation of acustomized document for signature that is virtually prepared and sent inan automated fashion by the pre-specified sender.

Document signing can be directly embedded in a system that maintains theURL link. Also, in the Service, a template indicating parties, roles andorder of document recipients describes the signing process. Furthermore,progress and status of a signing workflow is visible to the “virtualsender” from an online- or desktop-based console.

On completion of a document signing, results (e.g., signature data) areavailable for download by the virtual sender. Results and completeddocuments are also visible to the virtual sender via the console.Completed documents may be sent via email attachment to all parties.

Example PROCESS ACCORDING TO AN EMBODIMENT Step 1: Create a Template

As illustrated in FIG. 4A, this step specifies the following: 1) therecipients of the document including the user initiating the documentsigning, 2) the signing order, 3) the subject and message, 4) securityoptions and requirements, and 5) required data, signatures, initials,dates and other data to be collected in the signing process.

Step 2: Create a Web Form from the Template

As illustrated in FIG. 4B, the template created in Step 1 is identifiedas the instructions for a Web POWERFORMS form, referred to herein as a“Form.” The virtual sender is identified, security options are specifiedand the method for signing is indicated. At the end of this step theForm exists for signing.

Step 3: Get Link from Form Library

As illustrated in FIGS. 4C and 4D, this step creates the URL link thatcan start the Form signing process. The URL extracted in this step canbe inserted into a portal, intranet, email, document or other technologycapable of launching a Web URL.

Step 4: Publish the Link for Users

The URL to the Form is added to a portal, intranet, email, document orother technology, such as is illustrated in FIG. 4E, which the user canaccess to start the signing process.

Step 5: User Clicks the Link and Activates the Form

As illustrated in FIG. 4F, clicking the Form link from the portal,intranet, email, document or other technology launches the signingprocess. The first step of the signing experience is to identify theuser and any other required, un-addressed participants by supplying aname and email address.

Step 6: User Completes and Signs the Form

As illustrated in FIG. 4G, once the user and required parties areidentified, the user is presented with the document, customized with therecipients, data and other content specified in the template in Step 1.The user adopts a signature, reviews the document, supplies therequested data, adds any required signatures and completes the signing.

Step 7: Data is Returned to the Electronic Signature Service and MadeAvailable for Download

After completion, all signing data, document and signing history aremade available for download from the Forms Library. These data can bedownloaded on a document basis or for all documents submitted on aspecific Form.

Completed documents are delivered to all parties as attachments to thecompletion notification email as well as being made available in theconsole.

Web Based Forms

Overview

The Service allows users to create “self-help” transactions that do notrequire a send from an electronic signature service, such as may beprovided by DocuSign, Inc. This is optionally advantageous for accountopenings, Web-based forms and documents sent via email. An embodimentdoes not require the user to have known software products, such as ADOBEACROBAT Professional, and to know this software which is complex.

With the Service, Forms are made much more flexible by allowing a Formnot to have a PDF that launches it. By converting a stored Template to aForm, the service generates some extra information about how the Form isto launch, etc., and the service can launch it with a URL. (This issimilar to a PDF version, but the link is not to a PDF that starts theprocess, but rather it is directly to a template structure.)

The impact of this approach is to enable much more rapid deployment ofWeb-based signing for account openings, and other files, reducing costand complexity for the customer, and removing the need for products suchas ADOBE ACROBAT.

Features

The Service make a standard Template behave like a Form. In fact, theterm Form may be used to describe all PDF-based or Web-based forms.

Attributes of a Form:

1) Can be invoked by a signer via a URL. This URL may be sent in anemail, posted on a Web site, or embedded into a PDF document. The URLmay be overloaded with data to populate the Form fields and to populaterole information for recipients

2) Clicking the URL creates a new transaction and opens a secure browserto begin the signing process.

3) The signer who invokes the Form may provide any additional recipientdata. In other words, if there are five signers in the Templateworkflow, the signer invoking the Form may default to being the firstsigner. They may provide information about who the other recipients areas part of their signing. This can occur up front, and may only happenif there is more than one undefined role. (This is different than thecurrent PDF Form.)

4) Arguments may be able to be passed into the Form to provideinformation to complete form fields or assign roles. This allows anintegration to collect HTML form information and generate a string witharguments to pre-populate the Form (e.g., name, email for each role,field values, access code, ID check, phone auth). (This is differentthan the way the current PDF POWERFORMS forms work.)

5) In general, in some prior approaches, templates are uploaded; thereis no way to grab a template from a template library, etc. An embodimentis able to default to obtaining templates from the template library, notvia uploading. If a user has the template in the library, the user canmake a Form from it. If the template PDF has form fields, when the usercreates a Form from it, the user can elect to use them or not byselecting PDF or Web as the type of Form he is creating. When theservice creates a Form, the option to create “PDF” or “Web” Form candirect how it is constructed. If “PDF” is selected, the Form can havethe hyperlink to begin signing in a PDF process, and the PDF data fieldscan be usable. If “Web” is selected, then it can go directly to the Web,and NOT use the PDF to collect data.

6) Attributes that can be edited:

a) Template. Opens the template for both PDF and Web Forms.

b) Sender. Assign who the Form is “owned” by—who it can report statusback to, etc.

c) Usage settings. Maximum number of times it can be used and numberremaining

d) Frequency. How often it can be used; e.g., limit to every X minutesby the same signer.

e) Status. Active or inactive. If inactive, the link clicked may say“This document has been suspended and is not currently active. Pleasecontact the sender.”

f) Access Mode. Settings are Direct and Email. NOTE: When using Direct,the template may have some other form of authentication enabled such asaccess code, phone auth, or ID check to ensure the signer is identified.When the link is clicked, the Form opens immediately and processes asfollows:

(1) Ask for any other recipients. If they are required, the recipientsmay be provided (e.g., name, email)

(2) Execute any authentication requested

(3) Signing Process

(4) Once complete, go to the URL for completed envelopes. An embodimentmay add the URL for the completed signing event to be defined as part ofthe template.

g) Recipients. Optional edit of recipients that may also be accomplishedin other “edit” modes. Some embodiments may display routing order,roles, etc.

h) PDF owner Password. This protects the ability to edit the PDF in thecase of a PDF Form.

i) Document name

j) Email Subject

k) Email Text

l) An embodiment may include Instructions. These instructions may beused on the starting page for the signer. If instructions are entered,this may be the “Introduction” shown after the signer clicks the URL.This may enable more hand-holding for the signer, and in the event thetemplate has more than one role, it may be displayed on the same page aswhere the roles are asked for. This way, a user can define some text,such as “Welcome to Envoy Mortgage. You are applying for a loan. If youwill be co-signing, please enter the name & email of the co-signer aswell as your name and email.”

m) If the Template contains Required Fields with the name “NAME” and“EMAIL” for the First Role, then the service may not ask the user toprovide their name and email up front. The service can instead do itwith the template.

7) Data Management

a) It may be possible to download all the data collected by a Form byall its uses.

b) It may be possible to filter the download all the data by date range.

c) It may be possible to delete data collected by the Form, either alldata, or by date range.

d) In a PDF Form, data from all PDF fields may be gathered. In a Formall data from SecureFields may be gathered. If a PDF has both PDF andWeb SecureFields, all may be gathered.

e) Performance. It may be able to download 1000 records of 100 fields in10 seconds. Other embodiments have different performancecharacteristics.

f) Format of CSV file. In an embodiment, each Form may have only onerecord/row in a CSV file vs. each having duplicate rows.

g) Form subject, signer name, signer email, date/time completed (or noneif not complete), all field names in the PDF/SecureFields. For eachsigner the value they entered or the word “NA” if not assigned to thatperson.

8) Console listing

a) The console listing Forms may have the following columns. They may besortable, date searchable, and searchable by date used, sender, name,signing mode, status, type.

i) Name (Template name). Some embodiments compress “name” and “template”into one

ii) Sender. Identity of who it is assigned to

iii) Auth. Direct, email

iv) Used. The number of records collected by the PDF. (This valuechanges if the user deletes records.)

v) Remaining The number left before the limit (if set) is hit

vi) Last used date

vii) Status (active, inactive)

viii) TYPE: PDF or Web

b) Act on a Form. In the console the user may be able to use buttons ormenus to do the following:

i) Get form data from one selected form (download data dialog)

ii) Download

iii) Email. Creates email with hyperlink

iv) Links. Displays the hyperlink for the Form

v) Edit. Opens edit view

vi) Template. Opens the template to be edited

c) Create a new Form

i) Not all templates are Forms. To make a Form, the user selects atemplate, and clicks “create Form” menu/button

(1) This opens the “edit” panel for a Form, and allows the user toassign the “Form attributes”

(2) PDF or Web Form

(3) Mode

(4) Owner

(5) Usage settings

(6) Displays list of roles, and which are required or not

(7) Email subject and Name (for subsequent signers)

ii) Difference between Template and Form

(1) Forms have more attributes than Templates

(2) Mode, Times uses, multiple data collection, etc.

Within the present invention, plan mappings and settings may beavailable as follows:

1) According to an embodiment:

a) Available to Standard and Enterprise Accounts

b) Feature enabled as a plan item in the Billing Plan UI and thePlanItemsMaster table.

c) Service Admin can enable Forms

d) User Admin can enable Forms, e.g., some users can use Forms, some canauthor them.

e) Users can turn on/off Forms

2) Launch for existing customers: normally this may be off

3) Launch for new customers: normally this may be on.

DOCUSIGN POWERFORMS Forms

DOCUSIGN POWERFORMS forms (“Forms”) embody at least some of thedescribed techniques and combine the capabilities of PDF forms andmarket-leading DocuSign, Inc. electronic signing and workflowtechnology. DocuSign, Inc. provides an example electronic signatureservice, sometimes referred to as the “System.” Forms that werepreviously completed, signed and returned in hard copy via fax orovernight delivery can be widely distributed, conveniently completed andsecurely signed and returned electronically.

Forms add these capabilities to existing editable PDFs:

-   -   Forms can be distributed via email or the Web with a unique,        secure URL automatically generated by the System    -   All data provided via the PDF form may be returned and preserved        within the System and can be readily integrated into existing        applications    -   Centralized creation and management of Forms, including control        of all workflow elements—authentications, approvals and routing        order.

Forms work in conjunction with the System to allow a user to createtransactions that do not require the user to send documents from theSystem.

In an embodiment, there are two types of Form users: Form Senders andForm Administrators.

Form Senders: Form senders are allowed access to the Forms library andcan download and send Forms that are assigned to as the Sender. Senderscan also see completed, signed Forms that they sent, whether by email orother.

Form Administrators: Form administrators have the same access as Formsenders, but can also create and edit Forms. Additionally, Serviceadministrators can extract the completed form data set, in XML or CSVformat, from completed Forms.

Creating a Form

In an embodiment, only Service Administrators can create new Forms. If auser is not a Form Administrator, he or she may not use this section.

Creating a New Form

FIG. 4H shows a console configured to facilitate the creation of a newForm template.

1. The first step in creating a Form is creating a template. Follow thenormal steps for creating a template. Templates that may be used forForms preferably include only one document, although they can have anynumber of pages. When creating a template a user can use a PDF formcreated (or one that has been received from a third party) that hasactive form fields. The form fields are automatically converted toSecureFields when the PDF is added to a template. Once the template iscreated, the Form can now be created.

2. Go to the Manage Forms page Form tab in one of the following manners:(a) In the Console, click Forms and then click New Form. The user istaken to the Form tab on the Manage Forms page. (b) In the Console,click Forms and then click Forms Library. The user is taken to theManage Forms page. Click the New Form link. (c) In the Console, clickForms and then click Forms Library. The user is taken to the ManageForms page. Click the Form, tab.

3. Upload the template:

4. Click Template Library and locate the template.

5. To use a Professional template, click the “here” link, click Browse .. . and then locate the template. Professional templates have a fileextension of .dpd and are located, by default, in My Documents\DocuSignProfessional\Templates. In some embodiments, only one template may beuploaded per Form. Note: If a template used by a Form is edited andsaved at a later time, the changes may be automatically reflected in theForm. Once a template is uploaded, the Recipients, Document Settings andSender sections may be filled out with the information from thetemplate.

6. Review template information. The information in the Document Settingsand Sender section can be edited, but the information in the Recipientsmay be read-only and may be not editable. Any necessary changes to therecipients may be made in the template.

The Recipients section, shown in FIG. 4I, shows the routing order,recipient role or name, email address, recipient type (signer, certifieddelivery, carbon copy etc.), any access code associated with therecipient and if there is a security check (ID Check, PhoneAuthentication or False for no check) for the recipient.

If any of this information is incorrect, the user can correct thetemplate by clicking the template name link to open the template wizard,as illustrated in FIG. 4J. After saving the changes to the template, theuser may be returned to the Form tab.

7. Review Sender information. The default sender for a Form may be theForm Administrator creating the Form. The sender associated with theForm may be the person that is notified by email when a Form iscompleted. The sender may be also the person who sees the Form-generatedenvelopes in the Sent Items folder in their Console.

To change the Form sender, click the Change link to the right of thesender name, as illustrated in FIG. 4K. The list of all sendersassociated with the account appears. Select the sender and click Selectto continue.

Note: In one embodiment, only a single sender may be associated with theForm. If multiple senders need to be associated with a Form, createmultiple copies of the Form (one copy for each sender) and associate thesender with the Form.

8. Set the Usage Settings, as illustrated in FIG. 4L:

-   -   Maximum number of times the document can be used: The Form        administrator can specify the number of times the Form can be        used (signed). This can limit an account's exposure to excessive        envelopes usage by specifying a maximum number of times the Form        can be used. A Form administrator can edit this number anytime        after the Form is created, even if it has reached a previously        entered use limit. Each time a recipient clicks Begin Signing        for a document, the number of Uses remaining may be reduced by        one. If a recipient attempts to sign a Form that has reached its        maximum number of uses, an error message may be displayed to the        recipient saying the document is not available for signing.    -   Frequency the same signer can use the document: The Form        administrator can specify how often the same recipient can sign        the same Form. This may be accomplished by specifying a length        of time between signings. For example, if a Form is configured        to limit use to every 365 days, then the same recipient may only        be able to sign the Form once every year. If the recipient        attempts to sign the Form more frequently than allowed, an error        message may be displayed to the recipient saying the document is        not available for signing.    -   Document Status: This sets whether a document can be sent to        recipients. The default status for a Form may be Active, meaning        the Form can be sent and signed by recipients. If the status is        changed to Inactive, then the Form may not be emailed or        accessed by a recipient (even if they are entering the Form URL        or HTML link). If a recipient attempts to sign an inactive Form,        an error message may be displayed to the recipient saying the        document is not active and to contact the sender.

Signing Mode: In an embodiment, the Service supports two types ofsigning modes: Email and Direct.

The Email signing mode may be used to verify the recipient's identityusing email authentication before they can sign a document. After arecipient enters their email and clicks Begin Signing, an email with avalidation code for the Form may be sent to the recipient. If therecipient did not provide a valid email address, they may not be able toopen and sign the document.

The Email signing mode can also be used if someone other than therecipient will be completing the Form. For example, a call centerrepresentative completes the Form while they are on the phone with thesigner and provides the signer's name and email address in the Form.When the representative clicks Begin Signing, the recipient receives anemail notification to sign the document and they are not able to editthe information entered into the Form by the representative.

The Direct signing mode does not require any verification. After arecipient enters their email and clicks Begin Signing, a new browseropens and the recipient can immediately begin the signing process.

Since the recipient's identity is not verified using emailauthentication, it is strongly recommended that the Direct signing modeonly be used when the Form is accessible behind a secure portal wherethe recipient's identity is already authenticated or another form ofauthentication (for example: access code, phone authentication or IDcheck) is specified for the recipient in the template.

9. Review and set the Document Settings, as illustrated in FIG. 4M:

-   -   Document Name: This may be a required field. This is the name of        the Form. The default name of the Form may be the template name.    -   Email Subject: This may be a required field. This is the email        subject for any emails sent with this Form. The default email        subject may be the Message subject from the template.    -   Email Text: This may be a required field. And text is provided        for the Form. This text may be used in emails sent to signers        who are notified via email.    -   Signing Instructions: These may be additional instructions that        are shown on the starting page for the recipient. These        instructions are optionally advantageous if the recipient        accesses the Form by a method other than email. If instructions        are entered, they may be shown as an introduction after the        recipient accesses the Form.

10. Save the Form. After adding the template and making adjustments tothe settings for the Form, click Save to save the Form. The user is thenreturned to the Forms Library tab and the new Form is listed in theForms Library. To exit the Form tab without saving the Form, click theForm Library tab.

Sending Forms

In an embodiment, there are multiple ways that a Form can be sent to arecipient, but sending process typically begins by viewing the FormsLibrary.

Form administrators can see all Forms for all senders in their account.Form Senders may only see the Forms for which they are the sender. Thisis a form of access control that restricts Form Senders to only theForms they are allowed to use.

The Forms in the library can be sorted by clicking on the columnheadings. Forms can also be searched based on various criteria, forexample, by date last used/signed, document name, sender name, signingmode, or status.

Forms can be sent by email or by using a URL link or HTML settings or bysetting them up embedded in a Web page.

Sending by Email

1. In the Console, click Forms and then click Forms Library. The user istaken to the Manage Forms page Forms Library tab.

2. Select the Form to send by clicking the check box adjacent to theForm name.

3. Click Email, a new email is opened using a default email client. TheEmail Subject and Text from the Form is automatically entered in theemail and the URL link to the Form is added at the end of the emailtext. The user can review and edit the subject text for the email.

4. Send the email.

Sending by Attachment

This is similar to sending a Form by email, but in this case the Form isattached to an email rather than being linked from it. Note: In anembodiment, this method may only be used if the Form type is PDF.

1. In the Console, click Forms and then click Forms Library. The user istaken to the Manage Forms page Forms Library tab.

2. Select the Form to send as an attachment by clicking the check boxadjacent to the Form name.

3. Click Download and save the Form to the user's system.

4. Create a new email using an email client and attach the Form to theemail.

5. Fill out and send the email normally.

Sending by URL

1. In the Console, click Forms and then click Forms Library. The user istaken to the Manage Forms page Forms Library tab.

2. Select the Form to send by clicking the check box adjacent to theForm name.

3. Click Links, a dialog box is displayed with a URL link to the Formand HTML snippet. The user can copy and paste the URL in an email or theuser can copy the HTML snippet and add it to a Web page.

Forms Library

The Forms Library provides a common location for storing and accessingForms.

Form administrators can see all Forms for all senders in their account.Form Senders may only see the Forms for which they are the sender. Thisis a form of access control that restricts Form Senders to only theForms they are allowed to use.

Viewing the Forms Library

When a Service administrator and users view their Library, they may seethe following information for each Form:

-   -   Name (Template)—the Form name and template name    -   Sender—the sender associated with the Form    -   Auth—the Signing Mode (Email/Direct) for the Form    -   Used—the number of times the Form has been used    -   Remaining—the remaining number of times the Form can be used    -   Last Used—the date the Form was last sent or signed    -   Status—if the Form is Active or Inactive    -   Type—the type of document in the Form: PDF indicates the source        of the Form is a PDF file with active form fields, Web indicates        the source of the Form is a template.

The Forms Library list can be sorted by clicking on the column headings.The Forms Library can also be searched by date last used/signed,document name, sender name, signing mode, or status.

Retrieving Form Data

If the Form has been signed, a Form administrator can download the formdata for the Form, as follows:

1. From the Forms Library tab, select the Form to download data from byclicking the check box adjacent to the Form name and click Form Data theForm Data dialog box appears.

2. Optionally, filter by selecting a From and To date range. Afterentering or selecting the date range, click Apply Filter to apply thedate range filter, as shown in FIG. 4N.

3. Click Download XML or Download CSV to download the information as anXML or CSV file.

Editing a Form

Form administrators can edit a Form at any time. When editing a Form theForm administrator can replace or edit the template associated with theForm, change the document and usage settings and change the sender forthe Form.

1. From the Forms Library tab, Select the Form to edit by clicking thecheck box adjacent to the Form name and click Edit. The Form tab withthe Form information is displayed.

2. Edit the Form information in the same manner as creating a new Form.

3. Click Save to save changes.

Replacing a Form Template

If the administrator wants to update the template associated with theForm, they can do so by clicking on the template file name anddownloading the template to their local machine. They can then edit thetemplate and then upload the new template.

1. From the Forms Library tab, select the Form to replace the templatefor by clicking the check box adjacent to the Form name (the user canselect multiple Forms in the list) and click Replace Template theTemplate Selection dialog box appears.

2. Select a new template for the Form and click Save.

3. Click Save to save the change.

When a new template is uploaded for the Form, all signers who have anolder version of the Form will be presented with the updated PDFdocument to sign and will be processed based on the updated template(e.g., modified authentication methods, routing orders, etc.). Note: Ifthe underlying PDF document is replaced, the administrator making thechange may need to make sure the new version has the same fields (andfield names) as the old version or the Form may fail.

Copying a Form

A Form administrator can create multiple copies of a Form for thepurposes of assigning the Form to different senders. A unique copy ofthe Form will be created for each sender.

1. From the Forms Library tab, select the Form to copy by clicking thecheck box adjacent to the Form name (the user can select multiple Formsin the list) and click Copy, the list of all senders associated with theaccount appears.

2. Select the sender and click Select to continue.

3. Click Save to save the change.

Deleting a Form

Administrators can delete Forms from the Form Library. However, any dataassociated with the Form may be lost when the Form is deleted. If theuser wants to retain the Form data, the user can retrieve and save thedata or just set the Form status to Inactive.

1. From the Form Library tab, select the Form to delete by clicking thecheck box adjacent to the Form name (the user can select multiple Formsin the list) and click Delete, the system asks for confirmation of thedeletion of the Form.

2. Click OK to delete the Form or Cancel to cancel the action.

Embedding a Form in a Web Page

The user can select the appropriate Form within the library and click onthe “Links” button. A dialog will be displayed with a URL link to theForm and HTML snippet. The user can copy and paste the URL in an emailor the user can copy the HTML snippet and add it to a Web page.

Example Computing System

FIG. 5 is a block diagram of a computing system for practicing exampleembodiments of an electronic signature service 100. In the embodimentshown, the computing system 500 comprises a computer memory (“memory”)501, a display 502, one or more Central Processing Units (“CPU”) 503,Input/Output (“I/O”) devices 504 (e.g., audio processor, videoprocessor, keyboard, mouse, CRT or LCD display cards or drivers, and thelike), other computer-readable media 505, and network connections 506.

The electronic signature service 100 is shown residing in memory 501.The electronic signature service 100 interacts with client devices120-121 and the Web server 130 via a network 550. In other embodiments,some portion of the contents and some of or all of the components of theelectronic signature service 100 may be stored on and/or transmittedover the other computer-readable media 505. The components of theelectronic signature service 100 preferably execute on one or more CPUs503 to manage electronic signature processes, as described herein. Othercode or programs 530 (e.g., a Web browser or server, and the like) andpotentially other data repositories, such as data repository 520, alsoreside in the memory 501, and preferably execute on one or more CPUs503. Of note, one or more of the components in FIG. 5 may not be presentin any specific implementation. For example, some embodiments may notprovide other computer-readable media 505 or a display 502.

The memory 501 also includes a user interface manager 511 and anelectronic signature service application program interface (“API”) 512.The user interface (“UI”) manager 511 provides a view and a controllerthat facilitate user interaction with the electronic signature service100 and its various components. For example, the user interface manager511 provides interactive graphical user interface elements such as thosedescribed with respect to FIGS. 4A-4N. As discussed, such userinterfaces allow users to create and manage templates that representelectronic signature processes.

The API 512 provides programmatic access to one or more functions of theelectronic signature service 100. For example, the API 512 may provide aprogrammatic interface to one or more functions of the electronicsignature service 100 that may be invoked by one of the other programs530 or some other module. In this manner, the API 512 facilitates thedevelopment of third-party software, such as user interfaces, plug-ins,news feeds, adapters (e.g., for integrating functions of the electronicsignature service 100 into Web or mobile applications), and the like. Inaddition, the API 512 may be in at least some embodiments invoked orotherwise accessed via remote entities, such as by code executing on aremote client device, to access various functions of the electronicsignature service 100. For example, an application on the client device121 may upload signature data via the API 512. The API 512 may also beconfigured to provide code modules that can be integrated intothird-party applications and that are configured to interact with theelectronic signature service 100 to make at least some of the describedfunctionality available within the context of other applications.

In an example embodiment, components/modules of the electronic signatureservice 100 are implemented using standard programming techniques. Forexample, the electronic signature service 100 may be implemented as a“native” executable running on the CPU 503, along with one or morestatic or dynamic libraries. In other embodiments, the electronicsignature service 100 may be implemented as instructions processed by avirtual machine that executes as one of the other programs 530. Ingeneral, a range of programming languages known in the art may beemployed for implementing such example embodiments.

In addition, the embodiments described above may also be structured invarious ways, including but not limited to, multiprogramming,multithreading, client-server, or peer-to-peer, running on one or morecomputer systems each having one or more CPUs. Some embodiments mayexecute concurrently and asynchronously, and communicate using messagepassing, pipes, signals, or other communication techniques. Also, otherfunctions could be implemented and/or performed by eachcomponent/module, and in different orders, and by differentcomponents/modules, yet still achieve the described techniques.

Furthermore, in some embodiments, some or all of the components of theelectronic signature service 100 may be implemented or provided in othermanners, such as at least partially in firmware and/or hardware,including, but not limited to one or more application-specificintegrated circuits (“ASICs”), standard integrated circuits, controllers(e.g., by executing appropriate instructions, and includingmicrocontrollers and/or embedded controllers), field-programmable gatearrays (“FPGAs”), complex programmable logic devices (“CPLDs”), and thelike. Some or all of the system components and/or data structures mayalso be non-transitorily stored as contents (e.g., as executable orother machine-readable software instructions or structured data) on acomputer-readable medium (e.g., as a hard disk; a memory; a computernetwork or cellular wireless network or other data transmission medium;or a portable media article to be read by an appropriate drive or via anappropriate connection, such as a DVD or flash memory device) so as toenable or configure the computer-readable medium and/or one or moreassociated computing systems or devices to execute or otherwise use orprovide the contents to perform at least some of the describedtechniques. Some or all of the system components and data structures mayalso be stored as data signals (e.g., by being encoded as part of acarrier wave or included as part of an analog or digital propagatedsignal) on a variety of computer-readable transmission mediums, whichare then transmitted, including across wireless-based andwired/cable-based mediums, and may take a variety of forms (e.g., aspart of a single or multiplexed analog signal, or as multiple discretedigital packets or frames). Such computer program products may also takeother forms in other embodiments. Accordingly, embodiments of thisdisclosure may be practiced with other computer system configurations.

Embodiments of the invention are operational with numerous other generalpurpose or special purpose computing system environments orconfigurations. Examples of well known computing systems, environments,and/or configurations that may be suitable for use with the inventioninclude, but are not limited to, personal computers, server computers,hand-held or laptop devices, multiprocessor systems,microprocessor-based systems, set top boxes, programmable consumerelectronics, network PCs, minicomputers, mainframe computers,distributed computing environments that include any of the above systemsor devices, and the like.

Embodiments of the invention may include or be implemented in a varietyof computer-readable media. Computer-readable media can be any availablemedia that can be accessed by a computer and includes both volatile andnonvolatile media, removable and non-removable media. By way of example,and not limitation, computer-readable media may comprise computerstorage media and communication media. Computer storage media includevolatile and nonvolatile, removable and non-removable media implementedin any method or technology for storage of information such ascomputer-readable instructions, data structures, program modules orother data. Computer storage media includes, but is not limited to, RAM,ROM, EEPROM, flash memory or other memory technology, CD-ROM, digitalversatile disks (DVD) or other optical disk storage, magnetic cassettes,magnetic tape, magnetic disk storage or other magnetic storage devices,or any other medium which can be used to store the desired informationand which can accessed by computer. Communication media typicallyembodies computer-readable instructions, data structures, programmodules or other data in a modulated data signal such as a carrier waveor other transport mechanism and includes any information deliverymedia. The term “modulated data signal” means a signal that has one ormore of its characteristics set or changed in such a manner as to encodeinformation in the signal. By way of example, and not limitation,communication media includes wired media such as a wired network ordirect-wired connection, and wireless media such as acoustic, RF,infrared and other wireless media. Combinations of the any of the aboveshould also be included within the scope of computer-readable media.

According to one or more embodiments, the combination of software orcomputer-executable instructions with a computer-readable medium resultsin the creation of a machine or apparatus. Similarly, the execution ofsoftware or computer-executable instructions by a processing deviceresults in the creation of a machine or apparatus, which may bedistinguishable from the processing device, itself, according to anembodiment.

Correspondingly, it is to be understood that a computer-readable mediumis transformed by storing software or computer-executable instructionsthereon. Likewise, a processing device is transformed in the course ofexecuting software or computer-executable instructions. Additionally, itis to be understood that a first set of data input to a processingdevice during, or otherwise in association with, the execution ofsoftware or computer-executable instructions by the processing device istransformed into a second set of data as a consequence of suchexecution. This second data set may subsequently be stored, displayed,or otherwise communicated. Such transformation, alluded to in each ofthe above examples, may be a consequence of, or otherwise involve, thephysical alteration of portions of a computer-readable medium. Suchtransformation, alluded to in each of the above examples, may also be aconsequence of, or otherwise involve, the physical alteration of, forexample, the states of registers and/or counters associated with aprocessing device during execution of software or computer-executableinstructions by the processing device.

Embodiments of the invention may include or otherwise be implementedaccording to elements described in co-pending and commonly owned U.S.application Ser. No. 12/176,265 filed Jul. 18, 2008, which is herebyincorporated by reference as if fully set forth herein.

This patent application is intended to describe one or more embodimentsof the present invention. It is to be understood that the use ofabsolute terms, such as “must,” “will,” and the like, as well asspecific quantities, is to be construed as being applicable to one ormore of such embodiments, but not necessarily to all such embodiments.As such, embodiments of the invention may omit, or include amodification of, one or more features or functionalities described inthe context of such absolute terms.

While the preferred embodiment of the invention has been illustrated anddescribed, as noted above, many changes can be made without departingfrom the spirit and scope of the invention. Accordingly, the scope ofthe invention is not limited by the disclosure of the preferredembodiment.

1. A method in an electronic signature service, comprising: without use of a Portable Document Format processing module, creating a template that specifies required electronic signature data; transmitting a URL that identifies the template; receiving a request based on the transmitted URL; in response to the received request, preparing a form based on the template; presenting the form within a Web browser; and receiving the required electronic signature data.
 2. The method of claim 1 wherein the received request includes one or more arguments along with a portion of the transmitted URL, and wherein preparing the form includes populating the form with the included arguments.
 3. The method of claim 1 wherein the request is based on a URL that is dynamically generated by a module executing on a client device that executes the Web browser.
 4. The method of claim 3 wherein the module executing on the client device is a script executed by the Web browser.
 5. The method of claim 1 wherein the request is based on a URL that includes argument values received from data collection performed by a client device that executes the Web browser.
 6. The method of claim 1, further comprising: after transmitting the URL that identifies the template, modifying the template to include additional required electronic signature data; and in response to the received request, preparing the form to include controls for receiving the additional required electronic signature data.
 7. A system comprising: an electronic signature service computer configured, without use of a Portable Document Format processing module, to: transmit a URL that identifies a template that specifies required electronic signature data; receive a request based on the transmitted URL; in response to the received request, prepare a form based on the template; present the form within a Web browser; and receive the required electronic signature data.
 8. The system of claim 7 wherein the transmitted URL is included in a Web site accessed by the Web browser.
 9. The system of claim 7, wherein the electronic signature service computer is further configured to transmit the received electronic signature data to one or more recipients specified by the template.
 10. The system of claim 7, wherein the template specifies usage restrictions, and wherein the electronic signature service computer is further configured to enforce the usage restrictions.
 11. The system of claim 10, wherein the usage restrictions specify a maximum number of times the template can be used for electronic signature purposes.
 12. The system of claim 7, further comprising: a client device that executes the Web browser and that is configured, without use of a Portable Document Format processing module, to: receive the transmitted URL; dynamically generate the request based on the transmitted URL, by including one or more arguments in the generated request; and transmit the request to the electronic signature service computer.
 13. The system of claim 12, wherein the client device is further configured to execute a module in the Web browser that dynamically generates the request based on the transmitted URL.
 14. The system of claim 13, wherein the module is a script executing in the Web browser.
 15. The system of claim 12 wherein the client device is further configured to: collect data values from a user of the client device; and include the collected data values as the one or more arguments in the generated request.
 16. A computer-readable storage medium that includes instructions configured, when executed by a client device, to perform a method for interacting with an electronic signature service, the method comprising: without use of a Portable Document Format processing module, receiving a URL that identifies a template that specifies required electronic signature data; transmitting a request based on the received URL; receiving a form prepared based on the template; collecting the required electronic signature data by presenting the received form in a Web browser executing on the client device; and transmitting the collected data to the electronic signature service.
 17. The computer-readable storage medium of claim 16, wherein method further comprises executing a module in the Web browser that dynamically generates the request based on the transmitted URL.
 18. The computer-readable storage medium of claim 17 wherein the module is a script executing in the Web browser.
 19. The computer-readable storage medium of claim 16 wherein the method further comprises: collecting data values from a user of the client device; and including the collected data values as the one or more arguments in the generated request. 